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15 Verfahren und Vorrichtung zur Ubertragung von Simulations- 
modellen zwischen Simulatoren 



Die Erfindung betrifft eine Vorrichtung und ein Verfahren 
zur Ubertragung von Simulationsmodellen zwischen mindestens 
20 zwei Simulatoren. 

In der Simulationstechnik gibt es eine Vielzahl von ver- 
schiedenen Simulatoren, die die grafische komponentenorien- 
tierte Spezif ikation von Systemen als dynamisches Signal- 
f luSsimulationsmodell sowie die Simulation des dynamischen 

25 Verhalt ens dieser Simulationsmodelle erlauben. Beispiele 
fur diese Simulatoren sind Simulink, SystemBuild, ControlH, 
Beacon und Scade. Diese Simulatoren unterscheiden sich in 
ihrer Funktionalitat und Darstellungsmoglichkeit , wobei je- 
der seine eigenen Vor- und Nachteile hat. So ist beispiels- 

30 weise die Systemspezif ikation in dem einen Simulator beson- 
ders gut unterstutzt, wahrend in einem anderen Simulator 
die Simulations- und Analysemoglichkeiten umf angreicher 
sind. 

Eine wichtige und haufige Problemstellung beim Arbeiten mit 
35 diesen Simulatoren ist es, Simulationsmodelle, die mit ei- 
nem Simulator erstellt worden sind, auf einem anderen Simu- 
lator zu ubertragen. Das ennoglicht die Vor telle verschie- 
dener Simulatoren miteinander zu kombinieren. Durch die 
Moglichkeit der Ubertragung sind eine hohe Kostenersparnis 
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5 und ein entscheidender Zeitgewinn moglich. Fur eine effizi- 
ente Arbeit ist es auSerdem von grofier Bedeutung, die Simu- 
lationsmodelle wieder ruckzuiibertragen, also uber einen bi- 
direktionalen Ubersetzer zwischen zwei Simulatoren zu ver- 
fiigen. 

10 Der gegenwartige Stand der Technik fur die Ubertragung von 
Simulationsmodellen basiert auf zwei unterschiedlichen Vor- 
gehensweisen . Das erste Verfahren ist die direkte Uberset- 
zung des Simulationsmodells . Dazu wird ausgehend von der 
Beschreibung des Simulationsmodells, die fur einen Simula- 

15 tor A geschrieben wurde, eine Beschreibung des Simulations- 
modells erstellt, die von dem anderen Simulator B gelesen 
werden kann. Beim Ubersetzungsvorgang wird jeder einzelne 
Operator des Simulationsmodells des Simulators A durch ei- 
nen entsprechenden Operator des anderen Simulators B er- 

20 setzt. 

Diese Art der Ubersetzung erfordert, daS fiir jeden einzel- 
nen Operator des Simulator A, der im zu ilbersetzenden Simu- 
lationsmodell benutzt wurde, ein semantisch und syntaktisch 
aquivalenter Operator im anderen Simulator existiert. Da 
25 dies in der Kegel nicht gegeben ist, ist diese direkte Art 
der Ubersetzung nur im Ausnahmef all moglich. Haufig wird 
eine Untermenge von Funktionen definiert, die bei beiden 
vorhanden ist, und nur diese wird iibersetzt. 

Zudem unterscheiden sich die Operatoren oft im Detail, so 
30 daS zwar eine grundsatzliche Ubertragung moglich ist, sich 
aber das dynamische Verhalten des Simulationsmodells in ei- 
nem Simulator von dem in einem anderen Simulator unter- 
scheidet . 

Ein Beispiel fur diese direkte Art der Ubersetzung ist der 
35 zur Zeit von ISI und Verilog erstellte Simulator zur Uber- 
setzung von SystemBuild nach Scade . ( "Codesign Method and 
Integrated Tools for Advanced Embedded System (COMITY) " 
(Project reference 23015) . Von der Europaischen Union ge- 
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fordertes ^^jekt im Rahmen von "Esp:^^4", Teil des vier- 
ten Rahmenprogramms der Europaischen Union, Unterprogramm : 
"Software Technologies Software Intensive Systems Engi- 
neering" ) . 

Das zweite Verfahren fur die Ubertragung ist die Kommunika- 
tion zwischen zwei Simulatoren mittels einer Meta- 
Beschreibung. Dies heiSt, daS durch eine Exportf unktion der 
Simulatoren eine Beschreibung des Simulationsmodells er- 
stellt wird, die von beiden Simulatoren gelesen und ge- 
schrieben werden kann. Diese Meta-Beschreibung spezifiziert 
eine Beschreibungssprache, die dann dazu verwendet wird, 
die eigentlichen Inf ormationen in allgemeiner Art zu be- 
schreiben . 

Der lesende Simulator liest erst die Meta-Beschreibung, 
versucht diese zu verstehen und interpretiert dann anhand 
dieses Verstandnisses die Beschreibung. Problematisch hier- 
bei ist, dafi die Interpretationen des schreibenden und le- 
senden Simulators unterschiedlich sein konnen. AuSerdem 
konnen Inf ormationen verloren gehen, da die Simulationsmo- 
delle in der Meta-Beschreibung allgemeiner spezifiziert 
sind. 

Die semantische Identitat eines Simulationsmodells in bei- 
den Simulatoren ist nicht gegeben und die verlustfreie 
Rucktibersetzung ist im Regelfall nicht moglich. Hier konnen 
Parallelen zu menschlichen Sprachubersetzungen gezogen wer- 
den, wo es durch Ubersetzungsvorgange in verschiedene Spra- 
chen haufig zu Veranderungen und Unterschieden zu der ur- 
spriinglichen Bedeutung kommt . Ein Beispiel fur diese Art 
der Ubertragung ist CDIF, ein Quasi-Standard zum Austausch 
von Inf ormationen zwischen Simulationsmodellierungssimula- 
toren und Datenbanken, wie Johannes Ernst in "Data Inter- 
operability between CACSD and CASE Tools Using the CDIF" 
schreibt . 
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5 Es gibt grundsatzlich noch eine weitere Moglichkeit, zumin- 
dest das dynamische Verhalten eines Simulationsmodells von 
einem Simulator zum anderen zu ubertragen. Startpunkt ist 
ein Simulationsmodell , das mit einem Simulator spezifiziert 
wurde . Im folgenden wird der Quell-Code fiir das gesamte Si- 

10 mulationsmodell mittels eines automatischen Code-Generators 
dieses Simulators erzeugt. Der gesamte Quell-Code wird in 
den anderen Simulator als externes Modul eingebunden. Da- 
durch geht jedoch jede Struktur information verloren; das 
urspriinglich detaillierte Simulationsmodell wird zu einem 

15 einzigen Block. Eine weitere Bearbeitung im zweiten Simula- 
tor wird hierdurch unmoglich. 

Ferner gehen durch die generelle Codeerzeugung Informatio- 
nen verloren, wodurch das als externes Modul vorgegebene 
Simulationsmodell im zweiten Simulator keine ausreichend 
20 genaue Beschreibung darstellt. 

Aufgabe ist es, eine Vorrichtung und ein Verfahren zu 
schaffen, die die Ubertragung eines Simulationsmodells 
zwischen zwei verschiedenen Simulatoren erlauben, wobei 
Inf ormationsgehalt und Genauigkeit erhalten bleiben sollen, 
25 sich das dynamische Verhalten nicht andern soil und weitere 
Spezif ikationsarbeiten an dem Simulationsmodell moglich 
sein sollen. 

Gelost wird diese Aufgabe durch die Merkmale des 
Vorrichtunganspruchs 1 und des Verf ahrensanspruch 6, 

30 insbesondere durch eine Vorrichtung mit einem ersten 
Ein/Ausgabemittel, an das das Simulationsmodell von einem 
ersten Simulator ubertragen wird, mit einer 
Verarbeitungseinheit , die nach seiner Ubertragung das 
Simulationsmodell in einzelne Operatoren zerlegt und die 

35 Operatorenzuordnung speichert, die Operatoren in einer 
Operatorenbibliothek zusammenf aSt , mit Hilfe der 
Operatorenzuordnung als externe Operatoren durch einen 
zweiten Simulator semantisch aquivalent einbindbar sind und 



mit einem zweiten, die Opera torenbibliothek ausgebenden 
Ein/Ausgabemittel eine zusatzliche Operatorenzuordnung 
bereitstellt . 

Durch diese MaiSnahmen wird ein Simulationsmodell geschaf- 
fen, das insbesondere in beiden Richtungen, hin- und zu- 
ruck-iibersetzt warden kann, wobei semantische Inf ormationen 
erhalten bleiben. Dabei ist eine Ubertragung moglich, die 
keinen Unterschied macht, in welchem Simulator spezifiert 
bzw. simuliert wird. 

Das Simulationsmodell wird hierbei in Basisoperatoren zer- 
legt, die in einer universell simulatorenlesbaren Form in 
eine Operator enbibliothek exportiert werden. Die exportier- 
te Operatorenbibliothek liegt vorzugsweise in Form von com- 
pilierbaren Quell-Codes vor. 

Das zweite Ein/Ausgabemittel kann die Operatorenzuordnung 
sowohl export ieren als auch importieren, wodurch ein durch 
den zweiten Simulator entsprechend verandertes Simulations- 
modell mit den internen Operatoren des ersten Simulators 
durch die Verarbeitungseinheit erstellt und uber das erste 
Ein/Ausgabemittel an den ersten Simulator zuruck ubertragen 
wird. 

Die verf ahrensgemaSe Aufgabe wird gelost, indem das Simula- 
tionsmodell des ersten Simulators in seine Operatoren zer- 
legt wird, die Operatoren in eine Operatorenbibliothek so 
exportiert werden, daS sie von dem zweiten Simulator ge- 
nutzt werden konnen, und zusatzlich zu der Operatorenbi- 
bliothek eine Operatorenzuordnung exportiert wird, die so- 
wohl von dem ersten Simulator als auch von dem zweiten Si- 
mulator gelesen und vorzugsweise verandert werden kann und 
auf deren Basis das Simulationsmodell erstellt wird. 

Weitere vorteilhafte MaSnahmen sind in den Unteranspruchen 
beschrieben. Die Erfindung ist in der beiliegenden Zeich- 
nung dargestellt und wird nachfolgend naher beschrieben. 
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5 Die einzige Figur zeigt anhand eines schematischen Schalt- 
bildes zwei Simulatoren, die durch eine Vorrichtung zur 
Ubertragung von Simulationsmodellen miteinander verbunden 
sind. Dabei wird das erste Simulationsmodell in Komponenten 
zerlegt, die wiederiim in einer Operatorenbibliothek gespei- 
10 chert werden, Der zweite Simulator fiigt das Simulationsmo- 
dell liber die einbindbare Operatorenbibliothek mit Hilfe 
der Operatorenzuordnung zu einem neuen semantisch a^quiva- 
lenten Modell zusammen. 

In der Figur sind zwei Simulatoren 10 und 17 schematisch 
15 dargestellt, auf denen Simulationsmodelle 11 und 18 ablau- 
fen. Das erste Simulationsmodell besteht aus internen Ope- 
ratoren 12, die durch den ersten Simulator 10 bereitge- 
stellt werden. Die Operatoren 12 sind uber Zuordnungsvekto- 
ren 13 miteinander verbunden, wodurch die Semantik des Si- 
20 mulationsmodells 12 bestimmt wird. 

iiber ein erstes Ein/Ausgabemittel 22 wird das Simulations- 
modell 11 auf eine Vorrichtung zur Ubertragung von Simula- 
tionsmodellen 21 ubertragen. Diese Vorrichtung zur Ubertra- 
gung von Simulationsmodellen 21 besteht aus einer Verarbei- 
25 . tungseinheit 24 und einem zweiten Ein/Ausgabemittel 23. 

Zur Vorbereitung der eigentlichen Ubertragung wird durch 
die Verarbeitungseinheit 24 das erste Simulationsmodell 11 
des ersten Simulators 10 in seine Operatoren 12 zerlegt. 
Die Operatoren 12 werden in eine Operatorenbibliothek 15 so 

30 exportiert, dafi sie von dem zweiten Simulator 17 semantisch 
korrekt genutzt werden konnen. Dies erfolgt in der Regel 
durch Erzeugung von einem universellen Quell-Code fur jeden 
Operator 12 in der Operatorbibliothek 14. Durch 
Compilierung entsteht eine einbindbare Operatorenbiblothek 

35 15 . 

Die eigentliche Ubertragung erfolgt durch den Export einer 
Opratorenzuordnung 16, die sowohl vom ersten Simulator 10 
als auch vom zweiten Simulator 17 gelesen und verandert 
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5 werden kani^^ Aus dieser Veranderung^connen neue Zuord- 
nungsvektoren 2 0 erzeugt werden. 

Beide Simulationsmodelle 11 und 18 besitzen eine Reihe von 
Basis-Operatoren 12 . Alle diese Operatoren 12 werden von 
einem ersten Simulationsmodell 11 mit Hilfe der Vorrichtung 

10 zur Ubertragung von Simulationsmodell en 21 als Quell-Codes 
in die Operatorbibliothek 14 exportiert und dann nach Com- 
pilierung in die externe Operatorenbibliothek 15 uberfuhrt. 
Von dort konnen sie in das zweite Simulationsmodell 18 ein- 
gebunden werden, um fiir die Spezif ikation des Simulations- 

15 modells 18 verwendet zu werden. Im Detail heiSt das, dafi 
vom ersten Simulationsmodell 11 fiir die einzelnen Operato- 
ren 12 automatisch Quell-Codes in einer Programmiersprache 
erzeugt werden. Ein solcher Quell-Code wird mit einem auSe- 
ren Rahmen versehen, der die Nutzung jedes Operators als 

20 externer Operator in dem zweiten Simulationsmodell 18 er- 
moglicht . 

Die Erstellung der externen Operatorenbibliothek 15 aus den 
internen Operatoren 12 des ersten Simulationsmodells 11 ist 
eine Art Arbeitsvorbereitung . Der auSere Rahmen leistet zu- 
25 satzliche Funktionali tat um die Anbindung als externer Ope- 
rator in das zweite Simulationsmodell 18 zu ermoglichen, 
d.h. um den syntaktischen Erf ordernissen des zweiten Simu- 
lationsmodells 18 fur externe Operatoren zu entsprechen. 

Das Spezif izieren eines Simulationsmodells 18 im zweiten 
30 Simulator 17 erfolgt nur unter Nutzung der externen Opera- 
torenbibliothek 15. Damit ist die Ubertragbarkeit des zwei- 
ten Simulationsmodells 18 zu dem ersten Simulator 10 gesi- 
chert . 

Eine Vorrichtung zur Ubertragung von Simulationsmodellen 21 
35 kann das erste Simulationsmodell 11 unter Erzeugung einer 
Operatorenzuordnung 16 und einer Operatorenbibliothek 14, 
15 in das zweite Simulationsmodell 18 ubertragen. 
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5 Ziun Spezif izieren eines Modells kann also entweder in dem 
ersten Simulator 10 bei der Erzeugung eines Simulationsmo- 
dells 11 normal verfahren werden, indem das Modell aus in- 
ternen Einzeloperatoren 12 erstellt wird. Oder man kann mit 
dem zweiten Simulator 17 das zweite Simulationsmodell 18 
10 erstellen, indem nur externe Operatoren 19 verwendet wer- 
den . 

Voraussetzung hierfiir ist, daiS der zweite Simulator 17 das 
Einbinden von externen Operatoren 19 aus der externen Ope- 
ratorenbibliothek 15 in das zweite Simulationsmodell 18 er- 

15 laubt. Das gesamte zweite Simulationsmodell 18 besteht 
folglich aus externen Operatoren 19. Hinter jedem externen 
Operator 19 verbirgt sich ein interner Operator 12 des er- 
sten Simulationsmodells 11, Damit ist in dem zweiten Simu- 
lationsmodell 18 die gleiche Modellierung wie im ersten Si- 

20 mulationsmodell 11 moglich. Jeder Operator 12 bzw. 19 ist 
in beiden Simulationsmodellen 11 bzw. 18 aquivalent, da er 
jeweils auf Grundlage des ersten Simulationsmodells 11 ba- 
siert . 

Aquivalenz bedeutet, dafi die Funktionalitat jedes Operators 
25 12 und 19 in beiden Simulationsmodellen 11 und 18 gleich 
ist. Der Operator zeigt in beiden Simulationsmodellen das 
gleiche Verhalten. Das Gesamtverhalten eines Modells wird 
inf olgedessen gleich sein, da es die Summe der einzelnen 
Dynamiken darstellt. 

30 Ein Simulationsmodell 19, das im zweiten Simulator 18 spe- 
zifiziert wurde, kann zum ersten Simulator 10 iibertragen 
werden, indem jedem externen Operator 19 der entsprechende 
interne Operator 12 des ersten Simulators zugeordnet wird. 
Die Zuordnung bereitet keine Schwierigkeiten, da das zweite 

35 Simulationsmodell 18 aufgrund der beschriebenen Vorgehens- 
weise nur aus solchen externen Operatoren 19 besteht, fur 
die ein entsprechender interner Operator 12 existiert. In- 
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lich. 



Ein Ausfuhrungsbei spiel betrifft die Kopplung von Scade und 
Simulink. Scade ist ein Codegenerator von Verilog, der aus 
Spezif ikationen von Siitiulationsmodellen den Quell-Code er- 
10 zeugt. Ein solcher Quell-Code ist fur sicherheitsrelevante 
Anwendungen, beispielsweise in der Flugzeugindustrie, ein- 
setzbar. Scade hat nur eingeschrankte Moglichkeiten zur 
Eingabe von Simulationsmodellen und zur Simulation. 

Simulink ist ein Simulator von Mathworks, der in vielen Si- 
15 mulationsanwendungen zum Einsatz kommt . Er bietet eine be- 
nutzerf reundliche Eingabe von Simulationsmodellen und kom- 
fortable Simulation des dynamischen Verbal tens an. Er ist 
jedoch nicht geeignet, Quell-Codes fur sicherheitsrelevante 
Anwendungen zu erzeugen. 

20 Diese beiden Simulatoren, namlich Scade und Simulink konnen 
mittels des erf indungsgemaSen Verfahrens miteinander gekop- 
pelt werden. Dazu werden fiir alle von Scade bereitgestell- 
ten Operatoren Quell-Codes erzeugt. Ein solcher Quell-Code 
wird mit entsprechenden* Routinen erweitert, so daS man ihn 

25 als externen Operator in Simulink verwenden kann. 

Dies wird fiir jeden Operator einzeln vorgenommen. In dieser 
Weise wird eine Operatorenbibliothek 15 erstellt, mit der 
Modelle in Simulink spezif iziert werden konnen. Die Spezi- 
fizierung erfolgt in der komfortablen Umgebung von Simulink 
30 und das dynamische Verhalten des Modells kann in Simulink 
ana ly s i e r t we r den . 

Fur die Erzeugung von Quell-Codes fur sicherheitsrelevante 
Anwendungen mufi ein Simulationsmodell fur Scade erzeugt 
werden, Dazu wird die Model Ibeschreibung von Simulink nach 
35 Scade ubersetzt. Dabei wird jedem Operator der entsprechen- 
de Ursprungsoperator von Scade zugeordnet . Zwischen den 
Operatoren 11 und 19 beider Modelle besteht eine eindeutige 
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Zuordnung. Beide Modelle zeigen das gleiche dynamische Ver- 
halten, das in beiden Fallen auf dem von Scade erzeugten 
Code beruht . 
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Patentanspruche 

1. Vorrichtung zur Ubertragung von Simulationsmodellen 
(11, 18) zwischen Simulatoren (10, 17), 

15 - mit einem ersten Ein/Ausgabemittel (22), an das das Simu- 
lationsmodell (11) von dem ersten Simulator (10) ubertrag- 
bar ist, 

- mit einer Verarbeitungseinheit (24) , die nach seiner 
Ubertragung das Simulationsmodell (11) in einzelne Operato- 

20 ren (12) zerlegt und die Operatorenzuordnung (16) spei- 

chert, wobei die Operatoren (12) in einer Operatorenbiblio- 
thek (15) zusammenf aSbar sind, die mit Hilfe der Operato- 
renzuordnung (16) als externe Operatoren (19) durch den 
zweiten Simulator (17) semantisch aquivalent einbindbar 

25 sind, und 

- mit einem zweiten Ein/Ausgabemittel (23), das die Opera- 
torenbibliothek (15) ausgibt und zusatzlich die Operatoren- 
zuordnung (16) bereitstellt . 

2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet , 
30 daS das Simulationsmodell (11) in Basisoperatoren (12) zer- 

legbar und diese in einer universell simulatorenlesbaren 
Form in eine Operatorenbibliothek (15) exportierbar sind. 

3. Vorrichtung nach Anspruch 2, gekennzeichnet durch eine 
erste exportierte Operatorenbibliothek (14) in Form von 

35 compilierbaren Quell-Codes, die durch Compilation in eine 
einbindbare Operatorenbibliothek (15) umwandelbar ist. 
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5 4 . Vorrichtung nach den Anspriichen 1 bis 3 , gekennzeichnet 
durch ein zweites Ein/Ausgabemittel (23), das die Operato- 
renzuordnung (16) sowohl exportiert als auch importiert, 
wobei ein durch einen zweiten Simulator (17) entsprechend 
verandertes Simulationsmodell (11) mit internen Operatoren 

10 (12) des ersten Simulators (10) durch die Verarbeitungsein- 
heit (24) erstellt und uber das erste Ein/Ausgabemittel 
(22) an den ersten Simulator (10) ruckubertragbar ist. 

5. Vorrichtung nach den Anspruchen 1 bis 4, dadurch ge- 
kennzeichnet, dafi sie integrierter Bestandteil eines der 

15 Simulatoren (10, 17) ist. 

6 . Verf ahren zur Ubertragung eines Simulationsmodells zwi- 
schen einem ersten Simulatoren und einem zweiten Simulator, 
bei dem 

- das Simulationsmodell des ersten Simulators in seinfe Ope- 
20 ratoren zerlegt wird, 

- die Operatoren in eine Operatorenbibliothek so exportiert 
werden, daS sie von dem zweiten Simulator semantisch kor- 
rekt eingebunden werden konnen, und 

- zusatzlich zu der Operatorenbibliothek eine Operatorenzu- 
25 ordnung exportiert wird, die sowohl vom ersten Simulator 

als auch vom zweiten Simulator gelesen und vorzugsweise 
verandert werden kann und auf deren Basis das Simulations- 
modell erstellt wird. 

7. Verf ahren nach Anspruch 6, dadurch gekennzeichnet, daS 
30 die exportierte Operatorenbibliothek, bestehend aus Quell- 

Codes, in eine durch Compilation fiir den zweiten Simulator 
einbindbare Operatorenbibliothek umgewandelt wird, wodurch 
die Operatoren im Simulationsmodell des zweiten Simulators 
externe Operatoren werden, deren Semantik mit den Operato- 
35 ren des ersten Simulators iibereinstimmen . 
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8. Verfahren nach Anspruch 7, dadurch gekennzeichnet , daS 
die exportierte Operatorenbibliothek aus Quell-Codes und 
die einbindbare Operatorenbibliothek aus Objekt-Code beste- 
hen, die der zweite Simulator als externe Operatoren hinzu- 
linkt . 

9. Verfahren nach den Anspriichen 7 und 8, dadurch gekenn- 
zeichnet, dafi die Operatorenzuordnung das Simulationsmodell 
auf der Basis der exportierten Operatoren darstellt. 
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Zusammenf as sung 



Vorrichtung und Verfahren zur Ubertragung von Simulationsmo- 
dellen (11, 18) zwischen Simulatoren (10, 17), mit einem er- 
sten Ein/Ausgabemittel (22), an das das Simulationsmodell (11) 
von dem ersten Simulator (11) ubertragen wird, mit einer Ver- 
arbeitungseinheit (24) , die nach der Ubertragung des Simulati- 
onsmodells (11) das Simulationsmodell (11) in einzelne Opera- 
toren (12) zerlegt und die Operatorenzuordnung (15) speichert, 
wobei die Operatoren (12) in einer Operatorenbibliothek (12) 
zusammengefaSt werden, die mit Hilfe der Operatorenzuordnung 

(16) als externe Operatoren (19) durch den zweiten Simulator 

(17) semantisch acjuivalent einbindbar sind, und mit einem 
zweiten Ein/Ausgabemittel (23), das die Operatorenbibliothek 

(14) ausgibt und zusatzlich die Operatorenzuordnung (16) be- 
reitstellt . 



(Figur ) 
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